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(54) Titie: SYSTEM AND METHOD FOR AUTHENTICATION IN A MOBILE COMMUNICATIONS SYSTEM 
(57) Abstract 



The invention concerns authentication | 
to be performed in a telecommunications net- 
work, especially in an IP network. To al- 
low a simple and smooth authentication of 
users of IP networks in a geographical ly5 
large area, the IP network's terminal (TE1) 
uses a subscriber identity module (SIM) as 
used in a separate mobile communications 
system (MN), whereby a response may be^ 
determined from the challenge given to the 
identity module as input. The IP network 
also includes a special security server (SS), 
to which a message about a new user isp , 
transmitted when a subscriber attaches to the . | ^/ 
IP network.^The subscriber's authentication ' \ ' 
information containing at least a challenge- 
and a response is fetched from the said mo- 4 / 
bile communications system to the IP net- 
work and authentication is carried out based 
on the authentication information obtained SL0 
from the mobile communications system by 
transmitting the said challenge through the 
IP network to the terminal, by generating 
a response from the challenge in the ter-o)U 
minai's identity module and by comparing.. ' 
the response with the response received from 
the mobile communications system. Such a 7^1 
database (DB) may also be used in the sys- ' 
tern, wherein subscriber-specific authentica-J^M 
tion information is stored in advance, whereby* the 
when a subscriber attaches to the network. 
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SYSTEM AND METHOD FOR AUTHENTICATION IN A MOBILE COMMUNICATIONS SYSTEM 

Field of the invention 

The invention relates to authentication in a telecommunications net- 
5 work, especially in an IP network (IP = Internet Protocol), and also to im- 
provement of the network's data security features with the aid of the performed 
authentication. Authentication means verification of the identity of the party, 
such as the subscriber, who has generated data. Using authentication it is also 
possible to guarantee integrity and confidentiality of the said data. Authentica- 
10 tion may be performed for various purposes, such as for checking the right of 
use of network sen/ices. The invention is intended for use especially in con- 
nection with mobile terminals, but with the solution according to the invention 
advantages are also achieved in connection with fixed terminals. 

1 5 Background of the invention 

The strong growth in number of Internet users has been one of the 
most remarkable phenomena in communications in recent years. The rapid 
growth has also highlighted defects on the Internet. One of these is the poor 
data security of the network. The IP protocol version (IPv4) now in general use 

20 does not provide any such means, with which it would be possible to make 
sure that information arrived from the opposite end did not change during the 
transfer or that the information did in fact arrive from that source, who claims to 
have sent the information in question. In addition, it is easy to use various tools 
in the network for listening in to the traffic. For these reasons, those systems 

25 are very vulnerable which transmit non-encrypted critical information, e.g. 
passwords. 

The new IP version (IPv6) has internal characteristics that allow safe 
communication between Internet users. Because the transition to the new 
protocol will be slow, the data security features should be such that they are 
30 compatible with the present IP version (IPv4), and so that they can be added 
to this. 

Various such systems have been developed to improve the data 
security properties of the Internet where users can send the information en- 
crypted to the other party. One such system is the Kerberos, which is a service 
35 with which network users and services can authenticate one another and with 
which users and services can bring about encrypted connections between 
each other. The Kerberos system is utilised in one embodiment of the present 
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invention which will be described more closely hereinafter. 

Another current trend is the strongly increasing use of various mobile 
terminals. Along with this trend it is even more important that the terminals will 
have access to the data network also when being located outside their own 
5 home network. Such an access can essentially improve the usability of e.g. a 
portable computer, when the user is not in his/her usual working environment. 
Points of access may be located e.g. at airports, in railway stations, in shop- 
ping malls or on any other public premises, and the access may be wired or 
wireless. 

10 Systems of the described kind, which can be used for sending en- 

crypted information between parties, are mainly intended for fixed terminals 
and they require that the users are registered in advance as users of the 
service. It is a problem nowadays that for IP networks supporting mobility of 
the terminals there is no such existing and functioning authentication or key 

15 management system that would guarantee good geographical coverage and 
at the same time allow the user easily to have an authenticated and safe 
connection available to himself/herself in an area which is geographically as 
large as possible. 

20 Summary of the invention 

It is a purpose of the invention to eliminate the drawback described 
above and to bring about a solution, with which users of a telecommunications 
network, such as an IP network, can be simply and smoothly authenticated, 
almost irrespectively of where their network access point is located geographi- 
25 cally at each time. 

This objective is achieved through the solution defined in the inde- 
pendent claims. 

The invention utilizes the authentication method of an existing mobile 
communications network, especially the GSM network (Global System for 

30 Mobile Communications), in an IP network (or in any other network which is 
separate from the mobile communications network). This means that a user of 
the IP network in his IP network terminal uses the same (or an essentially 
similar) subscriber identification unit (SIM) as in his mobile phone or station. 
The idea is to fetch the subscriber's authentication data from the mobile com- 

35 munications network over to the IP network side and to carry out the authenti- 
cation in the IP network based on this data. The mobile network is not neces- 
sarily a GSM network, but it may be some other mobile communications net- 
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work, wherein authentication is used essentially in the same manner, e.g. a 
DCS network (Digital Cellular System), a GPRS network (General Packet 
Radio Sen/ice, which is a sub-network of the GSM) or a UMTS network 
(Universal Mobile Telecommunications System). 
5 In an advantageous embodiment of the invention, the user is regis- 

tered in response to a successful authentication into a separate key manage- 
ment system, preferably a Kerberos system, whereby it is possible then easily 
to bring about an encrypted channel between users communicating with one 
another. This is especially important when at least a part of the transmission 

10 path consists of a radio path. 

Owing to the solution according to the invention, users of the IP 
network are easily and smoothly authenticated and, in addition, the users are 
able to avail themselves of efficient security features in a geographically large 
area. This is due both to the widespread use of GSM networks and to the fact 

15 that roaming agreements between operators allow authentication of subscrib- 
ers entering a foreign network. E.g. today (1998) a Finnish GSM operator has 
common traffic agreements with operators working in more than 60 countries. 

Owing to the solution according to the invention, ISP (Internet Service 
Provider) operators typically also providing mobile communication services 

20 need not separately procure authentication and key management systems in 
the IP network, but they may use also for this purpose the features of the 
mobile communications network which they operate. 

With the solution according to the invention such an advantage is also 
achieved in connection with fixed terminals, that functions built in connection 

25 with the mobile communications network can be utilised in connection with 
Internet services. E.g. an organisation working both as a mobile communica- 
tion operator and as an ISP operator may use charging services built in con- 
nection with the mobile communications network for charging for the Internet 
services which he provides. When also fixed terminals are authenticated with 

30 the method according to the invention, much certainty is achieved that the bill 
will be directed at the correct subscriber. In addition, the subscriber can be 
authenticated, even if he attaches to the network from a foreign terminal. 

s A brief description of the drawings 

35 In the following, the invention and its preferred embodiments will be 

described more closely referring to the examples shown in Figures 1 ...10 in the 
appended drawings, wherein 
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Figure 1 illustrates an operating environment of the method in accordance with 
the invention, 

Figure 2 shows an exchange of messages between various elements, when 
5 the terminal attaches to the network or detaches from the network, 

Figure 3 illustrates the structure of those messages, with which the server of 
the system is told that the user has attached to the network or has 
detached from the network, 
Figure 4 shows an exchange of messages taking place between the various 
10 elements during authentication, 

Figure 5 illustrates the general structure of the messages shown in Figure 5, 
Figure 6 illustrates those elements of the system, which are used for acquiring 

a connection-specific encryption key between two terminals, 
Figure 7 shows an exchange of messages taking place in order to obtain an 
1 5 initial ticket from the Kerberos server, 

Figure 8 illustrates those parts of a terminal which are essential from the view- 
point of the invention, 
Figure 9 shows an exchange of messages taking place in order to obtain an 
encryption key for communication between two terminals, and 
20 Figure 1 0 illustrates an alternative embodiment of the system. 

Detailed description of the invention 

In the following the invention will be described with reference to a 
network environment, wherein mobility of the subscribers is supported with the 

25 aid of a Mobile IP protocol (MIP hereinafter). The MIP is such a version of the 
existing IP, which supports mobility of the terminals. (The MIP principle is 
described e.g. in the RFC 2002, October 1996, or in the article Upkar Varsh- 
ney, Supporting Mobility with Wireless ATM t Internet Watch, January 1997.) 

The MIP is based on the idea that each mobile host or mobile node 

30 has an agent (home agent) allocated for itself, which relays packets to the 
current location of the mobile node. When the mobile node moves from one 
sub-network into another, it registers with the agent (foreign agent) serving the 
concerned sub-network. The last-mentioned performs checks with the mobile 
node's home agent, registers the mobile node and sends the registration 

35 information to it. Packets addressed to the mobile node are sent to the mobile 
node's original location (to the home agent), thence they are relayed further to 
the current foreign agent, which will forward them to the mobile node. 
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Figure 1 shows a typical operating environment of the method in 
accordance with the invention. The heart of the system is the security server 
SS. which is connected both to the Internet and to a proxy server HP, which 
has access to a separate mobile network MN, which in this example is a GSM 
5 network. The proxy server forms a network element, which (in a manner to be 
described later) relays traffic between the security server and the home loca- 
tion registers HLR of mobile communications networks, which home location 
registers HLR are located in the home networks of the subscribers. In practice, 
both the proxy server and the security server are located on the premises of 
10 the network operator, e.g. in the same room, so that even if there is an IP 
connection between the security server and the proxy server, it is a secured 
connection. As the GSM network is known as such and the invention does not 
require any changes to be made in it, it is not described more closely in this 
connection. 

15 Users moving in the area of the system can use portable computers, 

PDA equipment, intelligent phones or other such terminals. Only one terminal 
TE1 is illustrated by reference mark CLIENT in the figure. For the present 
purposes, client generally means an object using the services provided by the 
network and carried out by the network servers. Client often means a program 

20 which connects with a server on behalf of the network user. 

Two sub-networks are shown in the figure and in practice they may be 
e.g. Ethernet local area networks, wherein TCP/IP packets are transmitted: the 
user's home network HN and the foreign network FN, to which terminal TE1 is 
assumed to be connected. These sub-networks are both connected to the 

25 Internet by way of a gateway GW (a router). The home network includes the 
home agent HA of the said mobile host and the foreign network correspond- 
ingly includes the foreign agent FA. Accesses to the sub-networks take place 
through access points AP, e.g. in a wireless manner, as is shown in the figure. 
The terminals are formed by two parts in the same way as the ordi- 

30 nary GSM telephone: of the subscriber device proper, e.g. a portable computer 
(with software) and of the SIM (Subscriber Identity Module), whereby from the 
viewpoint of the network the subscriber device becomes a functioning terminal 
only when the SIM has been pushed into it. In this case described as an ex- 
ample, the SIM is the subscriber identity module for use in the GSM network. A 

35 terminal may have access only to the IP network, or it may be a so-called dual 
mode device, which has access both to the IP network and to the GSM net- 
work. The access to the IP network takes place e.g. with the aid of a LAN card 
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in the terminal and to the GSM network with the aid of a GSM card, which in 
practice is a stripped telephone, which is located e.g. in the computer's 
PCMCIA expansion slot. 

In a preferred embodiment of the invention, there is also a Kerberos 
5 server KS in connection with the security server which is known as such and 
which is used for implementing encrypted connections in a manner to be 
described hereinafter. The security server and the Kerberos server may be 
physically in the same machine. 

For the security server to know when the user enters or exits the IP 

10 network, a channel is brought about between the security server and the home 
agent in the manner shown in Figure 2. In accordance with the MIP protocol, 
foreign agent FA continuously sends broadcast messages to its own sub- 
network, which messages are called by the name of "agent advertisement" 
and which are indicated by the reference mark AA in the figure. When the 

15 terminal attaches to the said sub-network, it will receive these messages and 
conclude from them whether it is in its own home network or in some other 
network. If the terminal finds .that it is in its home network, it will function with- 
out any mobility services. Otherwise the terminal will get a care-of address in 
the foreign network in question. This address is the address of that point in the 

20 network to which the terminal is temporarily connected. This address at the 
same time forms the termination point of the tunnel leading to the said termi- 
nal. Typically, the terminal gets the address e.g. from the above-mentioned 
broadcast messages, which the foreign agent is sending. Thereupon the 
terminal sends a RR (Registration Request) to its own home agent through 

25 foreign agent FA. The message contains, among other things, that care-of 
address, which the terminal just received. Based on its received request mes- 
sage, the home agent updates the said terminal's location information in its 
database and through the foreign agent it sends a Registration Reply RJReply 
to the terminal. In the reply message there is all the necessary information 

30 indicating how (on what conditions) the home agent has accepted the registra- 
tion request. 

All the messages between the terminal, the foreign agent and the 
home agent which were described above are normal messages in accordance 
with the MIP protocol. The mobile node may also register directly with the 
35 home agent. The above-mentioned RFC describes the rules, which determine 
whether the mobile node will register directly with the home agent or through 
the foreign agent. If the mobile node gets a care-of address in the manner 
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described above, the registration must always be made through the foreign 
agent. According to the MIP protocol, authentication is also performed in 
connection with the registration with the purpose to reduce the occurrence of 
errors in connection with the registration. The registration is based on a check 
5 value calculated from the registration message (from the registration request 
or reply), and the registration must be made only between that mobile node 
and that home agent, which have a shared fixed key (which is agreed upon in 
advance). Under these circumstances, the foreign agent is not necessarily 
able to authenticate the mobile node. This problem is aggravated, if as large a 

10 geographical coverage as possible is an objective in the system. 

According to the invention, a facility is added to the home agent to the 
effect that the home agent provides the security server with information about 
the terminal attached to the network, after the registration request message 
has arrived from the foreign agent. This message is indicated in the figure by 

15 reference mark MOB_ATTACH. Correspondingly, the home agent provides 
the security server with information about the terminal which has left the net- 
work after the terminal has detached from the network (after the terminal has 
detached from the network or after the lifetime of the address given to it has 
run out). In the figure, this message is indicated by the reference mark 

20 MOBJDETACH. To each type of message the security server sends an ac- 
knowledgement message (MOB_ACK). As regards their purpose of use, the 
MOB_ATTACH and MOBJDETACH messages correspond to the IMSI at- 
tach/detach procedures used in a GSM network. 

The home agent monitors the replies arriving from the security server 

25 and sends the messages again (with the same parameters), should no ac- 
knowledgement message arrive from the security server within a predeter- 
mined time, e.g. 30 seconds. 

Figure 3 illustrates the structure of the MOB_ATTACH, 
MOBJDETACH and MOB_ACK messages. In the messages there is a type 

30 field 31, which identifies the type of the message, a number field 32, which 
contains the random number or sequence number identifying the session, and 
an address field 33, which contains the client's IP address. The last-mentioned 
field is absent from the acknowledgement message. The messages are 
transmitted in fields reserved for the payloads of IP datagrams. 

35 Thus, when the terminal has attached to the network, the security 

server receives from the home agent information about the IP address of the 
concerned terminal. Thereupon follows authentication of the client, which will 
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be described in the following with reference to Figure 4. For the authentication, 
the security server first asks the client for the IMSI (International Mobile Sub- 
scriber Identity), which is stored on the SIM (the AUTHJD_REQ message). To 
this the client replies by giving his IMSI (which is a 9-byte identifier in accor- 
5 dance with the GSM specification) in the AUTH_ID_RSP reply message. The 
inquiry travels through the home agent to the termination point of the above- 
mentioned tunnel, but the reply comes directly from the terminal to the security 
server. 

If the clients IP address does not change often, it is preferable to 

10 store in the security server the IMSI identifiers corresponding to the IP ad- 
dresses, whereby identifiers need not be moved around unnecessarily in the 
network. Thus, the above-mentioned messages are not necessary. 

When the terminal has stated its IMSI identifier or when the security 
server has fetched it from its database, the security server starts the actual 

15 authentication. To enable authentication of the terminal's SIM, there must be a 
connection between the security server and the AuC (Authentication Center) 
located in connection with the home location register HLR of the subscriber's 
own GSM network. This is implemented with a proxy server HP, which func- 
tions as a connecting network element between the IP network and the GSM 

20 network, more precisely between the IP network and the SS7 signaling net- 
work utilized by the GSM network. The GSM network service needed in the 
authentication is MAP_SEND_AUTHENTICATION_INFO (GSM 9.02, v. 
4.8.0). This service is implemented by using the proxy server HP, which may 
be located on the premises of the local GSM operator. The security server 

25 transmits to the proxy server a SEC_INFO_REQ authentication request mes- 
sage, which contains a session identifier and the IMSI subscriber identifier. 
The proxy server for its part transmits to the authentication centre AuC an 
inquiry message in accordance with the MAP (Mobile Application Part) proto- 
col, which inquiry message is used to request an authentication triplet and 

30 which is normally transmitted between the VLR and the HLR. In response to 
this inquiry message, the HLR returns to the proxy server a normal authentica- 
tion triplet, which contains a challenge (RAND), a response SRES (Signed 
Response) and a key Kc (the connection-specific encryption key used in the 
GSM network). The proxy server relays the triplet further to the security server 

35 in a SECJNFOJRSP message. The security server stores the triplet and 
transmits the challenge (the AUTH_CHALLENGE_REQ message) further to 
the terminars SIM, which based on this message generates a response 
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(SRES) and a key Kc. The terminal stores the key and transmits the response 
(the AUTH_CHALLENGE_RSP message) (SRES) back to the security server. 

In the terminal there is preferably a database, wherein the challenges 
are stored. In this way it is possible to make sure that one challenge will be 
5 used just once. In this manner it is possible to prevent anyone from pretending 
to be a security server by snatching from the network the (non-encrypted) 
challenge and the response and by finding out the key Kc from these. If the 
same challenge occurs once again, no reply will be given to this challenge. 
The security server may also filter out those challenges which have already 

10 been used, and when required it may ask for a new authentication triplet from 
the GSM network, so that no such challenge which has already been used will 
be transmitted to the terminal. 

The proxy server HP functions in the system as a virtual visitor loca- 
tion register VLR, because at least as regards the authentication triplet inquir- 

15 ies it appears from the home register like a network element of the same kind 
as the genuine visitor registers of the GSM network. The proxy server also 
functions as a filter allowing access to the GSM system's signaling network 
only to authentication triplet inquiries. The proxy server does not either inter- 
fere with any other inquiries from the home register on the GSM network side. 

20 Figure 5 illustrates the general structure of the messages presented in 

Figure 4. In the messages there is a type field 51, which identifies the type of 
the message, a number field 52, which contains the random number or se- 
quence number identifying the session, and a payload field 53, the length of 
which varies depending on which message is at issue. In messages between 

25 the security server and the terminal, the two first fields occur in all messages, 
but there is no payload field in the AUTH_ID_REQ message. In the 
AUTH JD_RSP message the length of the payload field is 9 bytes (the length 
of IMSI is 1+8 bytes), in the AUTH_CHALLENGE_REQ message its length is 
16 bytes (the length of RAND is 16 bytes) and in the 

30 AUTH_CHALLENGE_RSP message its length is 4 bytes (the length of SRES 
is 4 bytes). In the messages between the security server and the proxy server, 
the length of the payload field is 9 bytes (IMSI) in the case of the 
SECJNFO_REQ message and nx28 bytes in the case of the 
SECJNFO_RSP message (in the triplet there is a total of 28 bytes and the 

35 network elements are generally configured so that they will transmit 1...3 
subscriber-specific triplets at a time). As mentioned above, normal GSM net- 
work signaling is used between the proxy server and the home location regis- 
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ter HLR. 

The security server compares the response it received from the termi- 
nal with the response arrived in the triplet and, if it is found in the comparison 
that the responses are the same, the authentication is successful. 
5 In response to a successful authentication, the security server starts a 

registration with the Kerberos server. In this context the Kerberos server 
means a process, which provides a Kerberos service. The Kerberos server is 
preferably located in connection with the security server, as is shown in Figure 
1. 

10 Kerberos is a system intended for authentication of network users and 

services. It is a trusted service in the sense that its every client trusts that the 
system's assessment of all its other clients is correct. Since the Kerberos 
system is known as such, and its operation is not changed in any way, it will 
not be described in detail in this context. The system is described e.g. in the 

15 document Steiner, Neuman, Schiller Kerberos: An Authentication Service for 
Open Network Systems, January 12, 1988, from which the interested reader 
may find background information, if he so desires. In the following description 
the same ways of marking will be used as in the above-mentioned document. 
The description is based on the Kerberos version 4. 
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25 


K x,y 


session key for x and y 




{abc}K x 


abc encrypted using x's personal key 




Tx,y 


x's ticket for using y. 



Figure 6 illustrates the objects of the Kerberos and authentication 
applications. It is assumed in the figure that the system has two clients, A and 

30 B. Each client may be a terminal, which has been authenticated by the security 
server in the manner described above, when it attached to the IP network, or 
one may be a "permanently" authenticated client, e.g. a server. The Kerberos 
application includes two parts: client program KC, which is located at the 
terminal, and server program KS, which is located at the security server. The 

35 server program also includes a ticket-granting server TGS. Correspondingly, 
the authentication application includes two parts: the client program AC, which 
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is located at the terminal, and the server program AS, which is located at the 
security server. Communication takes place with the aid of IP/MIP/IP-SEC 
stacks, which will be described in greater detail below. 

The following is a description of how the Kerberos protocol is used for 
5 bringing about a connection-specific key between terminals A and B. 

When the security server has found that the authentication was suc- 
cessful, it will start registration of the Kerberos client with the Kerberos server. 
In practice, this happens in such a way that the security server's authentication 
block AS registers the key Kc arrived in the authentication triplet (a) as the 

10 client's password and (b) as a password into the service formed for the client's 
IP address or for the IMSI subscriber identifier. The service is given some 
name which is determined in advance. 

Then the client may request a ticket for the ticket-granting server 
using the key Kc. This exchange of messages is shown in Figure 7. After the 

15 client has received the key Kc, it transmits to the security server (to the Kerbe- 
ros server) a message, with which it requests an initial ticket of the Kerberos 
system. There may be a brief predetermined delay between the reception of 
the key and the transmission of the message, so that the security server will 
have time first to perform the registration with the Kerberos server. After the 

20 delay, the terminal transmits to the security server a request in accordance 
with the Kerberos protocol, which always contains the client's identity (the IMSI 
or IP address) and the name tgs of a certain special service, the ticket-granting 
service. Upon receiving this inquiry the Kerberos server checks whether it 
knows the client If it does, it will generate a random connection-specific key 

25 K c tgs , which will be used later in data transmission between the client and the 
ticket-granting server. Thereupon the Kerberos server generates a ticket 
T c,tgs> with which the client may use the ticket-granting service. This ticket 
contains the client's name, the name of the ticket-granting server, the current 
time of day, the lifetime of the ticket, the client's IP address and the connec- 

30 tion-specific key just generated. Using the methods of marking described 
above, the contents of the ticket can be presented as follows T c tgs ={c, tgs, 
timestamp, lifetime, c-addr, K^^}. This ticket is encrypted using key K tgs , 
which is known only to the ticket-granting server and to the Kerberos server. 
Then the Kerberos server transmits as a response to the client a packet, which 

35 contains the encrypted ticket and a copy of the connection-specific key K c tgs . 
The response is encrypted using the client's own key Kc. The terminal stores 
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the ticket and the session key for future use. 

When the terminal has stored the ticket and the session key, it has 
access during the ticket's lifetime to the ticket-granting service and it is pre- 
pared to be in connection with a third party. 
5 Figure 8 illustrates those functional blocks of a terminal, which are 

essential from the viewpoint of the invention. The terminal is in connection with 
the network by way of the IP/MIP/IP-SEC protocol stack. IP/MIP/IP-SEC is 
such a known TCP/IP stack, which has built-in mobile IP characteristics and 
encryption functions. Seen from above, this stack appears just like an ordinary 

10 IP stack, but from below (from the network side) the said stack transmits 
encrypted information in accordance with a certain security policy. This secu- 
rity policy is determined by a separate security policy block SPB, which con- 
trols the IP/MIP/IP-SEC stack by indicating to the stack the other objects in the 
network to which encrypted information must be sent. These objects are 

15 generally defined in the security policy block with the aid of the terminal's IP 
address and port number. The definition can be made even finer by also 
defining those user identifiers, for which the encryption is done. In practice, the 
security policy block is built into the IP/MIP/IP-SEC stack, but in a functional 
sense it is a block in its own right. 

20 In addition to the security policy block, the terminal contains a key 

management block KM, which attends to management of keys. In connection 
with the key management block there is a database containing all the encryp- 
tion keys used by the terminal. The key management block can be imple- 
mented e.g. with the aid of the known PF_KEY API (API=Application Pro- 

25 gramming Interface). PF_KEY is a generic application programming interface, 
which may be used not only for IP layer security services, but also for other 
security services of the network. This API determines the socket protocol 
* family, which the key management applications use to communicate with parts 
of the operating system relating to the key management. Since the invention is 

30 not related to the known PF_KEY protocol, it will not be described more closely 
in this context. The protocol is described in the document McDonald, Metz, 
Phan: PFJCEY Management API, version 2, 21 April, 1997, where the inter- 
ested reader will find background information. 

In the key management block KM there are specific definitions for 

35 how and with which key the encryption is carried out to each network address. 
This definition may be made e.g. so that for each individual IP address and 
port that protocol and that key are stated which must be used when in connec- 
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tion with the port in question. 

When a packet which is to be transmitted outwards arrives in the 
IP/MIP/IP-SEC stack, the stack reads the packet's destination address and 
asks the security policy block SPB which is the encryption policy as regards a 
5 packet carrying the address in question. In response, the security policy block 
tells the IP/MIP/IP-SEC stack whether encryption is to be made, and if so, with 
which method the encryption is to be carried out. This information is relayed to 
the key management block KM. 

In the initial stage, the user has determined those connections for the 

10 security policy block, on which encryption must be used. If the security policy 
block states that encryption must be used and if the key management block 
finds that there is as yet no key for the terminal with which a connection is 
desired, the key management block will send a key request to the Kerberos 
client KC, who will request a server ticket for the concerned terminal from the 

15 security server's ticket-granting service. This signalling is illustrated in Figure 9. 
The terminal (the Kerberos client) sends to the ticket-granting server such a 
request in accordance with the Kerberos protocol, which contains the name (s, 
e.g. terminal B) of that server, for which the ticket is desired, a ticket T c t gs 
encrypted with the ticket granting server's own key K tgs for access to the 

20 ticket-granting service and an authenticator Ac, which is encrypted with a 
connection-specific key K c tgs . The authenticator is a data structure, which 
contains the client's name and IP address as well as the current time. Ob- 
serving the used method of marking Ac = {c, c-addr, timestamp}. 

The ticket-granting server checks the authenticator's information and 

25 the ticket T c tgs . If the ticket is all right, the ticket-granting server generates a 
new random session key K c s , which the client may use together with a third 
party of his choice. Then the ticket-granting server forms a new ticket T c s for 
the said third party, encrypts the ticket using the said third party's own key Ks, 
which is the same as the concerned subscriber's key Kc described above, and 

30 transmits the encrypted key together with the session key to the terminal. The 
entire reply is encrypted using key K c tgs . 

Upon receiving the reply message, the terminal unpacks the packet, 
transmits the first part {T c S }K S to the third party (to terminal B) and stores the 
new session key K c s in the key database. The terminal of the third party gets 

35 the recently generated session key K c s from the ticket by first decrypting the 
ticket with its own key Kc. Thereafter the new session key is available to both 
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terminals and encrypted data transmission may begin. 

When the Kerberos client has started his activity (when the client is 
registered with the Kerberos server), it must inform the IP/MIP/IP-SEC layer 
that it is able to serve session key requests. By using the PF_KEY protocol, 
5 this is done in such a way that the Kerberos client opens a special socket 
address into the kernel of the operating system and registers with the kernel 
with a SADB_REGISTER message. Then the PF_KEY protocol sends a 
SADB_ACQUIRE message each time when the key is needed for some out- 
bound interface. When receiving this message, the Kerberos client will act in 

10 the manner described above, that is, he sends a request to the ticket-granting 
server, of the received response it sends the part intended for the other party 
to the opposite end of the connection' and relays the received session key to 
the key management block. In addition, the Kerberos client listens to a certain 
socket address in order to notice any tickets that may arrive from other objects 

15 in the network. Having received such a ticket packet, it acknowledges recep- 
tion of the packet, unpacks the packet and relays the necessary keys to the 
key management system, whereby these keys can be used when connections 
exist with the concerned peer. 

When the terminal detaches from the network (message 

20 MOBJDETACH), the security server will remove both registrations from the 
Kerberos server. 

In practice, the terminal and the security server must have certain port 
numbers open for non-encrypted data transmission. Such ports are the port, 
through which authentication messages are transmitted between the terminal 

25 and the server (Figure 4), the port, through which tickets are transferred to the 
Kerberos clients, and the port, through which ticket requests are transferred. 

The authentication triplet can be sought in various ways. In a small- 
scale embodiment it is possible to use a virtual "HLR database", wherein a 
suitable number of authentication triplets is stored in advance. E.g. 10000 

30 triplets from each user would require 280 kilobytes of memory per user. Thus, 
e.g. a 6 GB disk could accommodate authentication triplets for more than 
21000 users. The authentication triplets may be loaded in advance when the 
user gets the service, by leaving the SIM module for a few hours in a smart 
card reader, which supplies the challenges to the module. The authentication 

35 triplets formed of the obtained responses are stored in the database using the 
modules information. This method also works with all SIM modules, irrespec- 
tive of the operators. The database may be located e.g. in connection with the 
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security server. Thus, it is not necessary to seek the authentication triplets) 
from the mobile communications network, but subscriber-specific authentica- 
tion triplets can be stored in advance in a database DB located in connection 
with the security server (compare with Figure 1). This means that proxy serv- 
5 ers are not necessarily needed at all. For some subscribers there may also be 
ready-made authentication triplets in the database and for some they may be 
fetched in real time from the mobile communications system. Authentication 
triplets can also be fetched in advance from the mobile communications sys- 
tem and placed in the database. 

10 In principle, it is also possible to copy each user's SIM module and 

use the copy in connection with the security server for authentication of the 
user (whereby no inquiry is made from the mobile communications network). 

These two methods described above make it possible for the used 
SIM modules to be modules dedicated solely for this purpose, and they do not 

15 necessarily relate to the mobile communications network's subscriber. 

The necessary authentication data can also be obtained from the 
GSM network e.g. from the connection between the MSC (Mobile Switching 
Centre) and the BSC (Base Station Controller). Thus, the proxy server need 
not necessarily emulate the visitor location register VLR, as was presented 

20 above, but it may also function as a network element of the same kind as the 
GSM network's base station controller. Such an alternative is illustrated in 
Figure 10, where the said network element is marked with the reference mark 
BP. In this case, the proxy server is thus a virtual base station controller, which 
is connected to the MSC (Mobile Switching Centre) in the same way as the 

25 GSM network's normal BSCs (Base Station Controllers). Looking from the 
mobile switching centre, the proxy server looks like an ordinary base station 
controller at least as regards the signalling relating to authentication. 

However, it is a problem in this second alternative that it requires 
considerably more complex signalling between the proxy server and the GSM 

30 network than the first alternative (Figure 1). Besides, in consequence of the 
authentication of the second alternative, the user will in the GSM system move 
into the area of the proxy server BP emulating a base station controller, but 
this is not a real base station controller in the sense that it would be able also 
to switch calls. Thus, this solution can be used only in connection with data 

35 services, and the terminal can not be the kind of dual mode equipment as 
mentioned above. 

Although the invention was described in the foregoing with reference 
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to a M IP enabled network, the solution according to the invention is not bound 
to this protocol. If the protocol to be used is IPv6, then there are no proper 
agents in the network. Hereby the information about when the user is in the 
network must be sought from the routing tables of the router in the user's 
5 home network. In practice, this means that the network must include a sepa- 
rate "locating agent", which by monitoring or "pinging" the router will notice that 
the user has entered the network and in consequence of this will start authen- 
tication by sending to the security server a message (MOB_ATTACH) about 
the new user. It is probable, however, that router manufacturers are designing 

1 0 a protocol from which it emerges when the user is in the network. 

Although the invention was described above with reference to the 
examples shown in the appended drawings, it is obvious that the invention is 
not limited to these, but it may be modified within the inventive idea presented 
in the appended claims. Authentication need not necessarily be performed in 

15 order to set up an encrypted connection between users, but as a result of a 
successful authentication one may perform e.g. registration with a mail server 
before transmitting e-mail messages to the user's machine. In this way a more 
reliable authentication is achieved than by the present methods based on 
passwords. In addition, in connection with the access points there may be 

20 local servers, which function as proxy servers for the security server proper, or 
the system may include more than one security server. Instead of the Kerbe- 
ros system it is also possible to use e.g. public key management, which is 
based on a x.500-database and on x.509 certificates. 
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Claims 

1 . Authentication method for telecommunications networks, especially 
for IP networks, in accordance with which method the identity of a subscriber 
attached to the network is authenticated, 

5 characterized by 

- in a network terminal (TE1), using a subscriber identity module (SIM) 
essentially of the same kind as in a known mobile communications system 
(MN), which identity module is such that a response is obtained as a result of a 
challenge given to it as input, 

10 - using a special security server (SS) in the network so that when a 

terminal attaches to the network, a message of a new user is transmitted to 
the security server, 

- fetching subscriber authentication information corresponding to the 
said new user from the said mobile communications system to the said net- 

15 work, which authentication information contains at least a challenge and a 
response, and 

- performing the authentication based on the authentication informa- 
tion obtained from the mobile communications system by transmitting the said 
challenge to the terminal through the network, by generating a response from 

20 the challenge in the identity module of the terminal and by comparing the 
response with the response received from the mobile communications system. 

2. Method as defined in claim 1, characterized in that fetching 
of the subscriber's authentication information from the mobile communications 
system is started from the security server (SS) in response to the said mes- 

25 sage. 

3. Method as defined in claim 1, characterized in that in 
response to a successful authentication, registration of the subscriber is per- 
formed as a client of a separate key management system. 

4. Method as defined in claim 3 for IP networks, characterized 
30 in that the known Kerberos system is used as the key management system. 

5. Method as defined in claim 4, characterized in that the 
subscriber-specific authentication information obtained from the mobile com- 
munications system also includes a key (Kc), whereby the subscriber is regis- 
tered as a client of the Kerberos system so that the key is registered (a) as the 

35 client's password and (b) as a password for a service formed for the client's IP 
address or for a subscriber identity (IMSI) used in the mobile communications 
system. 
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6. Method as defined in claim 1, characterized in that the 
subscriber's authentication information is fetched with the aid of a separate 
proxy server (HP), which functions as a network element emulating the visitor 
location register VLR of the mobile communications system and which re- 

5 quests the authentication information from an authentication centre AuC lo- . 
cated in connection with the subscriber's home location register HLR in the 
same way as the mobile communications system's own visitor location regis- 
ter. 

7. Method as defined in claim 1, characterized in that the 
10 subscriber's authentication information is fetched with the aid of a separate 

proxy server (BP) t which functions as a network element emulating the mobile 
communications system's base station controller and which is in connection 
with the mobile communications system's mobile switching centre (MSC) for 
fetching the authentication information from an authentication centre AuC 
15 located in connection with the subscriber's home location register HLR in the 
same way as the authentication information is fetched to the mobile communi- 
cations system's own base station controller. 

8. Authentication system for telecommunications networks, especially 
for IP networks, which system includes authentication means for authenticat- 

20 ing the identity of a subscriber who has attached to the network, 

characterized in that the authentication means include 

- a subscriber identity module (SIM) connected to the network's termi- 
nal (TE1), the module being essentially similar to the subscriber identity mod- 
ule used in a separate mobile communications system (MN), whereby a re- 

25 sponse can be determined from a challenge given to the identity module as 
input, 

- messaging means (HA) for sending a message when a terminal 
attaches to the network, 

- a special security server (SS) for receiving the said message, 

30 - means for requesting authentication information corresponding to a 

subscriber from the said mobile communications system (MN), which informa- 
tion contains at least a challenge and a response, and 

- on the side of the said network, data transmission and checking 
means for transmitting the challenge through the network to the identity mod- 

35 ule, for returning the response from the terminal to the network and for com- 
paring the received response with the response received from the mobile 
communications system. 
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9. System as defined in claim 8, characterized in that the said 
identity module is the subscriber' identity module (SIM) used in the GSM net- 
work 

10. System as defined in claim 8, characterized in that the 
5 messaging means are adapted into a home agent (HA) in accordance with the 

mobile IP network. 

1 1 . System as defined in claim 8, characterized in that the 
means for requesting authentication information include the said security 
server and a proxy server (HP, BP), which is connected to the GSM network. 

10 12. System as defined in claim 11, characterized in that the 

proxy server functions as a network element emulating the visitor location 
register VLR of the GSM network. 

13. System as defined in claim 11,characterized in that the 
proxy server functions as a network element emulating the base station con- 

1 5 trailer BSC of the GSM network. 

14. System as defined in claim 11, characterized in that the 
system further includes a Kerberos server (KS) which is known as such and as 
the user of which the subscriber will be registered as a result of a successful 
authentication. 

20 15. Authentication method for telecommunications networks, espe- 

cially for IP networks, in accordance with which method the identity of a sub- 
scriber attached to the network is authenticated, 
characterized by 

- in a network terminal (TE1), using a subscriber identity module (SIM) 
25 essentially similar to the one used in a known mobile communications system 

(MN), which identity module is such that a response is obtained as a result of a 
challenge given to it as input, 

- storing subscriber-specific authentication information in a database 
(DB), the information being in that way essentially similar to the information 

30 used for authentication in the said mobile communications system that it con- 
tains at least a challenge and a response, 

- using a special security server (SS) in the network so that when a 
terminal attaches to the network, a message about the new user is transmitted 
to the security server, 

35 - in response to the message, retrieving authentication information of 

the subscriber corresponding to the new user from the said database (DB), 
and 
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- performing authentication based on the authentication information 
obtained from the database by transmitting the said challenge through the 
network to the terminal, by generating a response from the challenge in the 
identity module of the terminal and by comparing the response with the re- 

5 sponse obtained from the database. 

16. Method as defined in claim 15, characterized in that the 
database is stored in connection with the security server. 

17. Method as defined in claim 15, characterized in that in 
response to a successful authentication, registration of the subscriber is per- 

10 formed as the user of a separate key management system. 

18. Method as defined in claim 17, characterized in that the 
known Kerberos system is used as the key management system. 

19. Authentication system for telecommunications networks, espe- 
cially for IP networks, which system includes authentication means for authen- 

1 5 tication of the identity of a subscriber attached to the network, 

characterized in that the authentication means include 

- a subscriber identity module (SIM), which is connected to a network 
terminal (TE1) and which is essentially similar to the subscriber identity module 
used in a separate mobile communications system (MN), whereby a response 

20 can be determined from the challenge given as input to the identity module, 

- messaging means (HA) for sending a message when a terminal 
attaches to the network, 

- a special security server (SS) for receiving the said message, 

- database means (SS, DB), which include a database (DB), wherein 
25 subscriber-specific authentication information is stored, which is in such a way 

essentially similar to the information used for authentication in the said mobile 
communications system that it includes at least a challenge and a response, 
and retrieval means (SS) for retrieving subscriber-specific authentication 
information from the said database in response to the message, 

> 

30 - on the side of the said network, data transmission and checking 

means for transmitting the said challenge through the network to the identity 
module, for returning the response from the terminal to the network and for 
comparing the received response with the response received from the data- 
base. 

35 20. System as defined in claim 19, characterized in that the 

said identity module is a subscriber identity module (SIM) used in the GSM 
network. 



11/17/2006, EAST Version: 2.1.0.14 



WO 00/02406 



21 



PCT/FI99/00565 



21 . System as defined in claim 19 f characterized in that the 
messaging means are adapted into a home agent (HA) in accordance with the 
mobile IP network. 

22. System as defined in claim 19, characterized in that the 
5 system further includes a Kerberos server (KS), which is known as such and 

as the client of which the subscriber is registered as the result of a successful 
authentication. 
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